多數團隊不是從零開始。你們有一疊寫了多年的測試案例,躺在 Excel 或測試管理系統裡。它們是最被低估的自動化資產:流程、資料、預期都在,只差翻譯。

好消息是,這條路業界已經鋪好了。Playwright 從 1.56 版起內建官方測試代理(Test Agents):planner 負責產出測試計畫、generator 負責把計畫變成測試程式、healer 負責修復失敗的測試。而對「既有案例轉換」這件事來說,你手上那疊案例,就是現成的測試計畫——planner 的工作,你們多年前就做完了。這篇給你一套批次轉換的工作法,把案例接上這條官方管線,不用一條一條土法煉鋼。

流程總覽:盤點、分級、轉換、驗證

圖 1:批次轉換的四步與節奏——小批量、快驗證、迭代前進

整套工作法一句話:小批量、快驗證、迭代前進。

一次丟三百條案例給 AI 是災難。不是它轉不動,是你驗不動。一批五到十條,轉完用突變法抽查,通過再下一批。第一批的修正回饋(「我們的預期都省略了登入前提,轉換時自動補上」)會讓第二批的品質直接跳級。

先看業界怎麼做:Playwright 官方測試代理

圖 2:轉換管線——案例先變 Markdown 計畫,再交給 generator 對著真實瀏覽器生成測試

在專案根目錄跑一個指令,就能裝好三個代理的定義檔:

npx playwright init-agents --loop=claude

這會在專案裡產生 planner、generator、healer 三個代理定義,以及連接 Playwright MCP 的設定(loop 也支援 VS Code、Codex 等環境)。這套代理和「把案例文字貼給 AI 硬翻」有一個本質差異:generator 不是憑文字想像 selector,它透過 Playwright MCP 開著真實瀏覽器,一邊照著計畫操作、一邊即時驗證定位與斷言,寫出來的才是對得上活 DOM 的測試。

所以轉換的正確姿勢是兩段式:先把 Excel 案例整理成 planner 格式的 Markdown 測試計畫(specs/.md,含情境、前置條件、步驟、預期結果),再讓 generator 讀計畫、對著測試環境生成 tests/.spec.ts。

另外兩個配角也各有位子:seed test 是所有生成測試的起點——把「已登入」這類共同前置條件做成 seed(通常是一個 fixture),generator 產出的每條測試都會複用它,正好對應你們案例裡那句永遠被省略的「前提:已登入」。而 healer 會在測試失敗時自動診斷、修定位、修等待——它是維護期的減壓閥,稍後再談它的邊界。

分級:不是每條案例都該轉

圖 3:A 直接轉、B 補了再轉、C 不轉

盤點時給每條打個等級。
• A 級,直接轉:步驟明確、預期具體、資料完整。可以直接整理成計畫、進入管線。
• B 級,補了再轉:寫著「驗證功能正常」這類模糊預期、或資料缺漏的。先補完再轉。
• C 級,不轉:探索性、易用性、「看整體順不順」的判斷類。它們本來就不是自動化的菜,下一篇會給它們正式的位子。

B 級值得多說一句。補預期的過程,其實是在升級案例本身。模糊的案例對手動執行者一樣是坑,只是人會自行腦補,AI 不會——AI 的不腦補,反而逼出了案例欠的債。這也和業界用這套代理的經驗法則一致:生成的測試有問題,回頭修的是計畫,不是測試。計畫是意圖的單一來源,測試只是它的可執行投影。

轉換第一段:案例 → Markdown 測試計畫

你可以這樣對 Claude Code 說:

附件是 8 條「訂單管理」的測試案例(欄位:編號、前置條件、步驟、測試資料、預期結果)。
請把它們整理成 Playwright planner 格式的 Markdown 測試計畫,存到 specs/orders-batch1.md:
1) 每個情境標題用「編號+功能:情境 → 預期結果」,保留原編號方便對照。
2) 共同前置條件(如登入)抽出來,對應專案的 seed test,不要在每條重複。
3) 任何一條若資訊不足、預期模糊、或你必須自行假設——不要猜,列出來問我。
4) 整理完先給我對照表:每條案例對應計畫中哪個情境、預期結果有沒有全數保留。

第 3 點是保險絲。AI 遇到模糊處的預設行為是合理腦補,而腦補出來的測試最危險——看起來完整,守護的卻是 AI 想像的需求。明確要求「不足就問、不准猜」,B 級案例會在這一段就被攔截出來,而不是變成程式之後才發現。

轉換第二段:計畫 → 測試程式

計畫審過之後,換 generator 上場:

用 playwright-test-generator 代理,從 specs/orders-batch1.md 產生測試。
1) 對測試環境 https://staging.example.com 執行,遵守 CLAUDE.md 的所有慣例。
2) 測試檔名與測試名稱保留原案例編號。
3) 產完給我對照表:每個情境對應哪個測試檔、斷言涵蓋了計畫中哪些預期結果。

generator 會照著計畫在瀏覽器裡實際走一遍,優先用 getByRole、getByLabel 這類語意化定位,邊走邊確認斷言成立。對照表則是驗收工具——預期結果和斷言對不上的,一眼可見。

驗證:healer 是助手,不是驗收者

第一次執行整批測試,難免有紅的。這時可以讓 healer 出手:它會重新檢視活的頁面、更新失效的定位、調整等待,然後重跑確認。UI 小改造成的失敗,它處理得又快又好。

但要畫清楚一條線:healer 分不清「測試壞了」和「產品壞了」,它也可能為了讓測試變綠而把斷言修弱。所以三件事仍然是你的:

• 突變法抽查:每批抽一兩條,故意把產品行為弄壞,確認測試真的會紅。這是防「斷言被修弱」的最後防線。
• 對照表核對:斷言必須覆蓋計畫裡的每一條預期結果,不多不少。
• 審 healer 的每一筆修改:它若把某條測試標成 skip,意思是「我認為功能壞了」——這是通報缺陷,不是修好了,要人來裁決。

轉完之後,手動案例怎麼辦

這裡有個升級:以前我們說「保留手動案例當意圖紀錄」,現在意圖紀錄有了更好的家——specs/*.md 測試計畫。它進版本控制、和測試程式一起演進,測試被質疑或要修改時,回去查它。原本的 Excel 案例降級為歷史存檔,而編號從案例、計畫一路留到測試名稱,三層對照隨時可查。

直接刪掉意圖紀錄的團隊,常在半年後為「這個測試當初到底想驗什麼」吵架。測試的意圖史,值得留底——只是現在它活在 repo 裡,而不是躺在 Excel 裡。

實戰演練:拿官方示範站走一遍

不用等公司專案,Playwright 官方示範站 https://demo.playwright.dev/todomvc 就能練。下面 10 條案例假裝是你們躺在 Excel 裡的資產,涵蓋新增、完成、取消、全選、編輯、取消編輯、篩選、清除、刪除:

把案例交給 Claude Code,分兩批轉。第一批(TC-001 ~ TC-005):

附件是 10 條 TodoMVC 測試案例(欄位:編號、前置條件、步驟、測試資料、預期結果),
受測網址 https://demo.playwright.dev/todomvc。請先轉 TC-001 到 TC-005 成 Playwright 測試:
1) 每條一個測試,名稱用「編號+情境 → 預期結果」,保留原編號。
2) 定位優先用 getByRole、getByPlaceholder、getByTestId,不用 CSS selector。
3) 前置條件寫在 beforeEach,不要在每條測試重複。
4) 任何一條若資訊不足或預期模糊——不要猜,列出來問我。
5) 轉完給我對照表:每條案例對應哪個測試檔、斷言涵蓋了哪些預期結果。

跑 npx playwright test,紅的修完、對照表核對過,再下第二批(TC-006 ~ TC-010):

繼續轉 TC-006 到 TC-010,規則同上。
另外,第一批我們發現的問題:〔填入你的修正回饋,例如「計數器斷言要用
toHaveText 精確比對,不要用 toContainText」〕——這批請直接套用。

第二批 prompt 裡那句「填入修正回饋」,就是整套工作法的核心:第一批的教訓,讓第二批品質跳級。最後抽一條做突變檢查——例如故意把 TC-003 的勾選步驟拿掉——確認測試真的會紅,一輪就完成了。等這套節奏熟了,再把第一批 prompt 的產出目標從測試程式改成 specs/*.md 計畫,接上 generator,就是完整的官方代理管線。